home *** CD-ROM | disk | FTP | other *** search
/ Floppyshop 2 / Floppyshop - 2.zip / Floppyshop - 2.iso / diskmags / 0022-3.564 / dmg-0122 / programm.ers / feedback.002 < prev    next >
Text File  |  1997-04-16  |  3KB  |  75 lines
  1.     Permission to reprint or excerpt is granted only if the
  2. following line appears at the top of the article:
  3.  
  4.     ANTIC PUBLISHING INC.,COPYRIGHT 1986.  REPRINTED BY PERMISSION.
  5.  
  6.     Now I will answer some of the question received recently in
  7. the ANTIC ONLINE Feedback (which is considerable faster than
  8. the regular mail this time of year).
  9.  
  10.     Q:  The AES manual states "when the application is first
  11. loaded into memory, it should make a DOS call to modify the
  12. application's memory allocation".  How is this done?
  13.  
  14.     A:  When a GEM application is first loaded by the AES,
  15. all of memory is allocated to it.  It must then release that
  16. portion which is  past the end of its field length.  This is
  17. necessary since the AES file  selector and the VDI open
  18. workstation and load fonts calls allocate memory,  and the
  19. application itself may need to do its own memory management.
  20.  
  21.     Fortunately, the standard routine APSTART will release
  22. memory for you if it is included as the first item in your
  23. link.  It uses a setblock call to TOS, after determining the
  24. proper length of your application.  To do so (quoting from
  25. APSTART), all "segment" lengths in  the base page are totaled
  26. and 0x100 is added for the base page length.
  27.  
  28.     Q:  When opening a blank window for a text screen is
  29. there a way of disabling the mouse so that you don't get a
  30. green patch when you inadvertantly move it?
  31.  
  32.     A:  Yes, you can turn off the mouse using the call
  33. graf_mouse(M_OFF, 0x0L);  Do this before clearing the window
  34. to  white.  If you later need to use the mouse, you can
  35. restore it with  graf_mouse(M_ON, 0x0L);
  36.  
  37.     Q:  Is it possible to patch GEM so that you must first
  38. click on the menu bar to active a drop-down, rather than just
  39. touching it with the cursor?  I find it mildly irritating to
  40. open a drop-down menu accidently when I am merely moving the
  41. cursor around.
  42.  
  43.     A:  As you may have guessed from the preceding
  44. discussion, the GEM menu algorithm is embedded deeply in the
  45. AES code and is not patchable. The "drop-down" architecture
  46. was chosen over "pull-downs" because it proved easier for
  47. novices.  Unfortunately, it does cause problems for
  48. experienced users who mouse around the screen much faster.
  49. One way to  partially avoid the problem is to design
  50. applications which have some  separation space between the
  51. menu bar and selectable objects.  On the Desktop, you can
  52. move file windows away from the bar and then save the new
  53. layout.
  54.  
  55.     Q:  How can I support multiple resolutions if I need to
  56. include icons and images in my resource?  Do I need to have
  57. an entire separate resource for each resolution, or is there
  58. a simpler way?
  59.  
  60.     A:  It is certainly possible to have an alternate
  61. resource for each screen mode, but it introduces problems in
  62. keeping their structure and naming identical.  Instead, you
  63. might consider building separate files containing only the
  64. bit image data for your resource, with one version for each
  65. resolution.  You might do this by copying the image
  66. definitions from the .C file emitted by the RCS.
  67.  
  68.     After you have loaded the resource, allocate some memory
  69. and  read in the appropriate image file.  You will then have
  70. to link in the  image data by modifying the pointers in your
  71. resource's BITBLK and  ICONBLK structures.  You will need to
  72. determine in advance which objects  must be modified, and in
  73. what order their data occurs in the image file.
  74.  
  75.